Re: draft-chan-idr-bgp-lu2-00.txt

Hi,

I will attend IETF meeting in Singapore.
Would I be granted a chance to present on the proposed draft?
If yes, which date and time slot should I expect?

Rgds
Louis

From: Robert Raszuk <[email protected]>
Sent: Tuesday, November 5, 2019 2:55 AM
To: Louis Chan <[email protected]>
Cc: idr@ietf. org <[email protected]>
Subject: Re: draft-chan-idr-bgp-lu2-00.txt

Louis,

My point is that VPN label should never be carried in BGP-LU - it does not belong there in transport layer.

It is fine to carry a color for it and do the mapping at PEs or ASBRs option B, but not the value.

Thx,
R.

On Mon, Nov 4, 2019 at 7:46 PM Louis Chan <[email protected]<mailto:[email protected]>> wrote:
Hi Robert,

The VPN label is just an example for the service. Here it might be a L3VPN.
Subsequent session of the draft indicates there would be a mapping between a VPN service prefix and the transport tunnel (i.e. label stack) via color.

/Louis

From: Robert Raszuk <[email protected]<mailto:[email protected]>>
Sent: Tuesday, November 5, 2019 1:30 AM
To: Louis Chan <[email protected]<mailto:[email protected]>>
Cc: idr@ietf. org <[email protected]<mailto:[email protected]>>
Subject: draft-chan-idr-bgp-lu2-00.txt

Hi Louis,

Can you elaborate on the intended meaning of encoding a VPN label in your draft as part of the transport encoding ?


           The following is an example



           PE1----ABR1-----ABR2-----PE2



           PE1 will send the following labels with a color 100 path



           [2001 13001 801 16], where



           2001 - SR label to reach ABR1



           13001 - Binding-SID label to reach ABR2. Underlying tunnel type is RSVP-TE



           801 - Binding-SID label to reach PE2. Underlying tunnel type is SR-TE



           16 - a VPN label

           ^^^^^^^^^^^^^^^^



Many thx,

Robert.

_______________________________________________
Idr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/idr