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

From: "George, Wes" <[email-masked]>
Date: Wed, 19 Feb 2014 12:47:26 -0500

Adding MPLS WG, some responses below, and I’m sure my co-authors will
chime in as well. Thanks for the review!

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)
>
>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?

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Mach Chen <[email-masked]>
Date: Thu, 20 Feb 2014 02:05:24 +0000

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!

> >IGP used for label mapping is proposed by Segment routing, there may
> >need a sub section for this.
> 
> 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).
> >
> >      *  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.
> 
> 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

---

From: Mark Tinka <[email-masked]>
Date: Thu, 20 Feb 2014 04:17:14 +0200

On Wednesday, February 19, 2014 07:47:26 PM George, Wes 
wrote:

> (https://mailarchive.ietf.org/arch/search/?q=BGP+Identif
> ier&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?

As you point out, today, operators have considered Router-
ID's (be they for BGP or other routing protocols enabled on 
a router) as an arbitrary 32-bit integer that looks like an 
IPv4 address, but really isn't treated as one.

In IPv6-only networks, today's routers still require a 32-
bit Router-ID, and general practice is to hard-code this 
into deployments for BGP and other routing protocols 
(especially for single stack IPv6 routers).

In the future, when the majority of new ISP's will be IPv6 
single stack, I don't foresee this practice stopping. There 
is sufficient RFC 1918 space for operators to use in order 
uniquely deploy Router-ID's across their backbone.

Having said that, I could foresee issues where different 
single stack IPv6 routing domains interconnect, and there is 
the potential for Router-ID clashing if sourced from RFC 
1918 space. This could have an impact on the BGP Route 
Selection algorithm and/or setup and maintenance of BGP 
sessions. In this case, having a 128-bit Router-ID might be 
a sure-fire simple way to guarantee Router-ID uniqueness 
across inter-domain routing. 

The other option would be for both routing domains to pre-
agree on Router-ID's that do not clash, but this adds 
complexity to both intra- and inter-domain routing.

Mark.

---

From: Markus Jork <[email-masked]>
Date: Fri, 28 Feb 2014 22:43:08 +0000

This is a very useful effort and should be adopted as a WG document.
It is difficult to say whether the current draft has captured all the potential problems but it appears quite exhaustive already. It is also clearly written and technically sound.

The use case discussion in section 2 seems overly defensive and doesn't contribute much to the document, it might as well be removed for the sake of brevity.

Some minor technical feedback:

The verdict at the end of section 3.3.2.1 is:
"Gap: Major. RFC4659 needs to be updated to explicitly cover use case #2".
I believe this is meant to say "RFC 4798". But I'm not sure that's fair. RFC 4798 is very explicitly covering only the 6PE use case. That's all it is trying to achieve, so adding "4PE" to this RFC would be overloading it. If there are gaps with a "4PE" use case not sufficiently covered by existing specs, and people are actually interested in doing this, then this should probably be addressed by a new RFC dedicated that use case?

In section 3, the reference for RSVP-TE should be RFC 3209 and not RFC 5420.

I also noticed two very minor typos:
3.3.2: "RFC4364 defines as VPN-IPv4 address type"
3.3.2.3: "tunnelling over an single-Address"

-Markus

> From: Loa Andersson [mailto:[email-masked]]
> Sent: Saturday, February 15, 2014 3:07 AM
> To: David Allan I; Mach Chen; Markus Jork; draft-george-mpls-ipv6-only-
> [email-masked]; [email-masked]; VIGOUREUX, MARTIN
> (MARTIN); Aissaoui, Mustapha (Mustapha)
> Subject: draft-george-mpls-ipv6-only-gap-04.txt
> 
> Dave, Mach, Markus and Mustapha,
> 
> You have been selected as MPLS Review team reviewers for
> draft-george-mpls-ipv6-only-gap-04.
> 
> Note to authors: You have been CC'd on this email so that you can know
> that this review is going on. However, please do not review your own
> document.
> 
> Note 2: All the IPv& expertise we have in the MPLS review team are
> listed as contributors on this draft. I've therefore asked Mustapha
> to review.
> 
> Reviews should comment on whether the document is coherent, is it
> useful (ie, is it likely to be actually useful in operational
> networks), and is the document technically sound?  We are interested
> in knowing whether the document is ready to be considered for WG
> adoption (ie, it doesn't have to be perfect at this point, but should be
> a good start).
> 
> Reviews should be sent to the document authors, WG co-chairs and
> WG secretary, and CC'd to the MPLS WG email list. If necessary, comments
> may be sent privately to only the WG chairs.
> 
> Are you able to review this draft by March 1, 2014?
> 
> 
> Thanks, Loa
> (as MPLS WG chair)
> --
> 
> 
> Loa Andersson                        email: [email-masked]
> Senior MPLS Expert                          [email-masked]
> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>