Subject: [spring] Implementation Report on draft-ietf-spring-segment-routing-ldp-interop

From: Lizhenbin <[email-masked]>
Date: Tue, 3 Nov 2015 01:21:36 +0000

Hi Folks,

I proposed my concern on the implementation of interoperability between LDP and SR again in IETF. I also would like to remind you of my draft again:

https://tools.ietf.org/html/draft-li-spring-compare-sr-ldp-rsvpte-00

In this draft I explained the possible challenges of SR comparing LDP. And in sec 6 I summary the possible challenge of Interoperability between SR and LDP/RSVP-TE. Until now I believe that there will be much challege for the implementation. In fact in order to solve the possbile issue I mentioned in the draft, the mapping server has been introduced. Is it some central-control based solution in the IGP/LDP distributed environment? I worried that there still more issues which have to be solved and propose great challenge for the implementor on the feature and when new mechanisms are introduced they will propose new challenges again. If so, this may be nightmare for the developer of the feature. Hope if there were the implementation the implementation report on draft-ietf-spring-segment-routing-ldp-interop-00 can be publised accomanying the draft to demonstrate what can be done and maye what can not be done. This will be much helpful to the implementors and operators to consider their possible choice to cope with this interop issue: take the challenge, leave it or replace the LDP network with SR all at once without introducing the interoperability issue.

Best Regards,

Zhenbin(Robin)

---

From: Jon Mitchell <[email-masked]>
Date: Wed, 4 Nov 2015 20:46:48 -0500

> https://tools.ietf.org/html/draft-li-spring-compare-sr-ldp-rsvpte-00

With the hopes of clarifying Lizhenbin's comments which I found a bit
hard to follow both at the mic and in this email I went through this
draft and found the most applicable section to be 4.2 (proxy egress) in
the draft above versus Section 6 which he referenced.  I believe this is
the concern he is raising (Lizhenbin - please feel free to correct me).

In inter-as option C and like technologies, there are two ways to
distribute received label information from ASBR/PE to other PE's, either
via BGP label-unicast or IGP (make other networks PE's look similar to
this network's PE from label stack standpoint by redistribute prefixes
into IGP and have PE advertise via LDP which results in a 2 label
approach versus 3 label in BGP case).  I'll refer to these as C1 (IGP)
and C2 (BGP).

draft-ietf-spring-segment-routing-ldp-interop-00 already does a good job
of describing that option C/CsC/Seamless MPLS can be supported in it's
Section 6 (using C2), but it could add a bit more text I think admitting
that it can't support using a C1 model as many providers have deployed
and therefore an extra label will be incurred.  At least I can't think
of an easy way to support having multiple ASBR's handle mapping these
dynamically learned prefixes from the other AS to the same SID...

-Jon

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 6 Nov 2015 20:26:40 +0000

In-line [Uma]:

--
Uma C.

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Jon Mitchell
Sent: Wednesday, November 04, 2015 5:47 PM
To: Lizhenbin
Cc: [email-masked]
Subject: Re: [spring] Implementation Report on draft-ietf-spring-segment-routing-ldp-interop

> https://tools.ietf.org/html/draft-li-spring-compare-sr-ldp-rsvpte-00

With the hopes of clarifying Lizhenbin's comments which I found a bit hard to follow both at the mic and in this email I went through this draft and found the most applicable section to be 4.2 (proxy egress) in the draft above versus Section 6 which he referenced.  I believe this is the concern he is raising (Lizhenbin - please feel free to correct me).

In inter-as option C and like technologies, there are two ways to distribute received label information from ASBR/PE to other PE's, either via BGP label-unicast or IGP (make other networks PE's look similar to this network's PE from label stack standpoint by redistribute prefixes into IGP and have PE advertise via LDP which results in a 2 label approach versus 3 label in BGP case).  I'll refer to these as C1 (IGP) and C2 (BGP).

draft-ietf-spring-segment-routing-ldp-interop-00 already does a good job of describing that option C/CsC/Seamless MPLS can be supported in it's Section 6 (using C2), but it could add a bit more text I think admitting that it can't support using a C1 model as many providers have deployed and therefore an extra label will be incurred.  At least I can't think of an easy way to support having multiple ASBR's handle mapping these dynamically learned prefixes from the other AS to the same SID...

[Uma]: "easy way" - fair description.
		Two not so easy ways for Option C-  2 labels with SR:
			1. Make sure all your ASBRs have same SRGB provisioned and make sure same global index is assigned for redistributed PE prefixes from other AS
					- Only way is to use same vendor nodes( if possible)
			2. Use context labels/recursive label lookups using anycast segments
					- All vendors may not support and support is limited to few platforms even with the same vendor

Apart from the above Section 6 of this draft alludes to few practical issues with LFA/RLFA when LDP-SR interworking in place..
--
Uma C.

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Thu, 12 Nov 2015 17:03:44 -0800

Hi Robin

The mapping server is already implemented. And it is not that complex at all

As for the support of inter-AS option "C", there are two solutions
(1) "draft-filsfils-spring-sr-recursing-info-01" provides a way to use 
the prefix-SID of one address for another one. So refering to the second 
figure in the your draft "draft-li-spring-compare-sr-ldp-rsvpte-00", 
ASBR12 can  inject the IP addresses of "PE21" and "PE22" in the IGP of 
AS1 and use the IP address of ASBR11 itself as the "Recursing SID Address".
(2) "draft-ietf-spring-segment-routing-ldp-interop" suggests using 
BGP-LU to distribute the remote domain information as Jon Mitchell 
mention in his email. At the first glance, it may seem like an issue for 
some platforms. However, as it is mentioned in 
"draft-bashandy-rtgwg-bgp-pic-02" which was presented in the last IETF, 
it is actually very easy to flatten a 2 level recursion into a single 
level of recursion, thereby supporting any hardware capability

Thanks

Ahmed

On 11/2/2015 5:21 PM, Lizhenbin wrote:
>
> Hi Folks,
>
> I proposed my concern on the implementation of interoperability 
> between LDP and SR again in IETF. I also would like to remind you of 
> my draft again:
>
> In this draft I explained the possible challenges of SR comparing LDP. 
> And in sec 6 I summary the possible challenge of Interoperability 
> between SR and LDP/RSVP-TE. Until now I believe that there will be 
> much challege for the implementation. In fact in order to solve the 
> possbile issue I mentioned in the draft, the mapping server has been 
> introduced. Is it some central-control based solution in the IGP/LDP 
> distributed environment? I worried that there still more issues which 
> have to be solved and propose great challenge for the implementor on 
> the feature and when new mechanisms are introduced they will propose 
> new challenges again. If so, this may be nightmare for the developer 
> of the feature. Hope if there were the implementation the 
> implementation report on 
> draft-ietf-spring-segment-routing-ldp-interop-00 can be publised 
> accomanying the draft to demonstrate what can be done and maye what 
> can not be done. This will be much helpful to the implementors and 
> operators to consider their possible choice to cope with this interop 
> issue: take the challenge, leave it or replace the LDP network with SR 
> all at once without introducing the interoperability issue.
>
> Best Regards,
>
> Zhenbin(Robin)
>
>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 13 Nov 2015 08:15:28 +0100

> The mapping server is already implemented. And it is not that complex at

​Great news ! Can you send link to github containing the src code ?

Thx,
Robert​.