Subject: Re: [mpls] draft-george-mpls-ipv6-only-gap-04.txt

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sat, 8 Mar 2014 07:28:56 +0000

Hi Mach,

Please see inline,

>2). BGP-LS may need to be mentioned somewhere

Ummm...BGP-LS isn¹t particularly related to MPLS. Wouldn¹t it be out of
scope of this document?

>3. Section 3.3.3.  MPLS-TP
>
>"  MPLS-TP does not require IP (see section 2 of RFC 5921 [RFC5921]) and
>   should not be affected by operation on an IPv6-only network.
>   Therefore this is considered out of scope for this document.
>
>   Gap: None.
>"
>I am not sure the above statement is accurate, MPLS-TP can run without
>IP, it also can run with IP.

Agreed.

> Section 5.3. of RFC6370, 2nd paragraph, it says:
> "GMPLS [5] is based on RSVP-TE [2].  This section defines the mapping
> from an MPLS-TP LSP_ID to RSVP-TE.  At this time, RSVP-TE has yet to
> be extended to accommodate Global_IDs.  Thus, a mapping is only made
> for the network unique form of the LSP_ID and assumes that the
> operator has chosen to derive its Node_IDs from valid IPv4 addresses."
> 
> In an IPv6 only network, there should be no such an valid IPv4 address,
>so some updates
> may need here.

I agree. We could add the following text to section 3.2.6:

// 

2nd para of Section 5.3 of RFC6370 describes the mapping from an MPLS-TP
LSP_ID to RSVP-TE with an assumption that Node_IDs are derived from valid
IPv4 addresses. This assumption fails in an IPv6-only network.

Gap: Minor; Section 5.3. of RFC6370 needs to be updated.
//

> In addition, LSP_TUNNEL_IPv6 Session Object use IPv6 addresses+tunnel
>ID+LSP ID to 
> identify an LSP, it needs to evaluate whether "32-bit Node_ID + Tunnel
>ID + LSP ID² is
> sufficient to identify an IPv6 LSP. Seems it's fine, but the mapping
>definition may need
> some changes or clarification.

Is this in the context of RSVP-TE [rfc3209] ?

-- 
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco

-----Original Message-----
From: 'Mach Chen' <[email-masked]>
Date: Wednesday, February 19, 2014 at 9:05 PM
To: Wes George <[email-masked]>,
"[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [mpls] draft-george-mpls-ipv6-only-gap-04.txt

>Hi George,
>
>> -----Original Message-----
>> From: George, Wes [mailto:[email-masked]]
>> Sent: Thursday, February 20, 2014 1:47 AM
>> To: Mach Chen; [email-masked];
>>[email-masked]
>> Subject: Re: draft-george-mpls-ipv6-only-gap-04.txt
>> 
>> Adding MPLS WG, some responses below, and I¹m sure my co-authors will
>>chime
>> in as well. Thanks for the review!
>
>You are welcome!
>
>> 
>> Wes George
>> 
>> 
>> On 2/19/14, 2:23 AM, "Mach Chen" <[email-masked]> wrote:
>> 
>> >Specific comments:
>> >
>> >1. Section 3.2
>> >
>> >IGP used for label mapping is proposed by Segment routing, there may
>> >need a sub section for this.
>> 
>> WG] I believe we¹ll need to make sure the folks in SPRING are
>>considering
>> IPv6-only operation and put a more generic note that draft technologies
>>(like
>> EVPN and Segment Routing) are not in scope for the gap analysis (see my
>> previous on-list response)
>
>OK.
>
>> >
>> >2. Section 3.2.3.1.
>> >
>> >1) To give a comprehensive introduction of TE link advertisement, it
>> >may need to mention IGP extensions for inter-AS TE link advertisement
>> >(RFC5316 and RFC5392).
>> >
>> >2). BGP-LS may need to be mentioned somewhere
>> >
>> >3. Section 3.3.3.  MPLS-TP
>> >
>> >"  MPLS-TP does not require IP (see section 2 of RFC 5921 [RFC5921])
>>and
>> >   should not be affected by operation on an IPv6-only network.
>> >   Therefore this is considered out of scope for this document.
>> >
>> >   Gap: None.
>> >"
>> >I am not sure the above statement is accurate, MPLS-TP can run without
>> >IP, it also can run with IP. IMHO, there should be some gaps need to
>> >soloved in case of IPv6-only network. As I know, there is at least one
>> >gap need to be mentioned.
>> >RFC6370, second para of section 4  states:
>> > "The Node_ID is a unique 32-bit value assigned by the
>> >   operator within the scope of a Global_ID."
>> >
>> >And then section 5.3 Mapping to RSVP Signaling, where
>> >
>> >      *  Extended Tunnel_ID = A1-Node_ID
>> >      *  Tunnel Sender Address = A1-Node_ID And in RFC3209, section
>> >4.6.1.2. LSP_TUNNEL_IPv6 Session Object is defined. So, in IPv6-only
>> >network, it obviously that Extended Tunnel_ID and Tunnel Sender Address
>> >cannot be mapped to Node_ID anymore.
>> 
>> WG] There¹s a related discussion happening in IDR/v6ops right now
>> 
>>(https://mailarchive.ietf.org/arch/search/?q=BGP+Identifier&qdr=w&f_list=
>>id
>> r&gbt=1 starting 14 Feb) responding to a proposal to make BGP Router ID
>>a
>> 128 bit field because of the lack of direct mapping between the 32 bit
>>field and a
>> potentially 128 bit address on an IPv6-only device. So far, there has
>>been
>> significant feedback from operators that in the case where these are
>>simply fields
>> that contain an arbitrary 32 bit value whose only requirement is that
>>it is unique
>> across some scope, we need to be clear that the link between that
>>field¹s value
>> and any particular IPv4 address is merely by convention, not by
>>protocol necessity,
>> and therefore the solution in an IPv6-only network may simply be to
>>note that in
>> order for this to work, the operator must have a method to derive a
>>unique value,
>> either manually/programmatically assigned at provisioning time, or via
>>some sort
>> of mapping from an IPv6 address present on the box. I¹m inclined to
>>handle this
>> potential gap in the same way, since the problem and discussion in IDR
>>is in no
>> way specific to BGP, but I think it¹s something that we need to discuss
>>in this
>> specific context - I.e. does it break anything if the value is
>>arbitrary and not linked
>> to an IP address present on the device?
>
>Yes, I noticed that discussion and am fine with the 32-bit Router ID.
>
>As its current definition, the Node_ID is already an arbitrary 32-bit
>value that is unique within the scope it used. The problem here is that
>how to identify an IPv6 LSP with the current MPLS-TP identifier
>definition.
>
>Section 5.3. of RFC6370, 2nd paragraph, it says:
>   "GMPLS [5] is based on RSVP-TE [2].  This section defines the mapping
>   from an MPLS-TP LSP_ID to RSVP-TE.  At this time, RSVP-TE has yet to
>   be extended to accommodate Global_IDs.  Thus, a mapping is only made
>   for the network unique form of the LSP_ID and assumes that the
>   operator has chosen to derive its Node_IDs from valid IPv4 addresses."
>
>In an IPv6 only network, there should be no such an valid IPv4 address,
>so some updates may need here.
>
>In addition, LSP_TUNNEL_IPv6 Session Object use IPv6 addresses+tunnel
>ID+LSP ID to identify an LSP, it needs to evaluate whether "32-bit
>Node_ID + Tunnel ID + LSP ID" is sufficient to identify an IPv6 LSP.
>Seems it's fine, but the mapping definition may need some changes or
>clarification. 
>
>Best regards,
>Mach
> 
>> 
>> 
>> 
>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls