[mpls] 答复: Segment Routing vs. “Label Stacking” in draft-ietf-mpls-sfc-00

Hi Authors,
The effort can be seen for the draft to decouple from the draft draft-xuclad-spring-sr-service-chaining. 
But there are still ambiguous places which should be clarified in the draft. I have following comments:
1. Section 7: MPLS Label Stacking
As my understanding MPLS label stacking can be composed by the labels for swap and the labels for pop. That is, MPLS label 
stack is not only composed by labels for pop. For section 4, we can derive the label stacking from the use cases which can 
be composed of labels for swap and the labels for pop.Or for section 8 the mixted mode can also be label stacking. But for 
section 7, it seems MPLS label stacking means only being composed of labels for pop. I think the two cases are not 
consistent and the MPLS label stacking is not an accurate word.

2. Section 7: SFC Context Label
As the definition of SFC Context Label, does it meant that it has nothing with the node segment/label which is used in the 
draft draft-xuclad-spring-sr-service-chaining?

3. From Section 13 and Section 14, it can be worked out for the forwarding behavior of the label swapping mode for SFC.
1) For the label stacking mode "It then uses the revealed context/SF values to determine how to route the packet to the 
next SFF, SFFy.", could you clarify following details:
-- Does the context value or the SF value or the both determine how to route? How to create the label forwarding entries 
for the context/SF? 
2) "Further labels may be imposed to tunnel the packet from the SFFx to SFFy.": Can the further labels mean the MPLS label 
using as the indicator of the VRF based on the text 
"  Consider the mechanism used to indicate to which Virtual Routing and
   Forwarding (VRF) an incoming MPLS packet should be routed in a Layer
   3 Virtual Private Network (L3VPN) [RFC4364].  In this case, the top
   MPLS label is an indicator of the VRF that is to be used to route the
   payload."

4.In section 7 and section 13, the case that there is one SF for one SFF is defined. Could you clarify if there are 
multiple SFs for one SFF ( for example, SF1 and SF2 are accessed through Service Function Forwarders SFFx) what is the 
encapsulation and what is the forwarding behavior?

Best Regards,
Robin

________________________________________
发件人: mpls [mpls-bounces@ietf.org] 代表 Loa Andersson [loa@pi.nu]
发送时间: 2018年5月15日 16:38
收件人: Andrew G. Malis; mpls@ietf.org; sfc@ietf.org
主题: Re: [mpls]  Segment Routing vs. “Label Stacking” in draft-ietf-mpls-sfc-00

 >chair-hat off>

Andy,

Inlime please.

On 2018-05-07 13:15, Andrew G. Malis wrote:
> I just realized that I was a bit more terse in my email than I should
> have been. When I said that the MPLS WG had never discussed “Label
> Stacking”, well of course we have the label stack, but we had never
> discussed, prior to Segment Routing, using the label stack as a method
> to do source routing via only popping labels, with no label swapping
> along the path.

I think that this would be an argument if

    POP'n'go == SR

but an entirely different case if

    POP'n'go > SR

I think we can see from the uses case proposed by the authors of
draft-ietf-mpls-sfc there are a lot of additional things for POP'n'go,
and that it motivates its place in an MPLS wg draft.

Please send comments on Adrian mail with proposed changes.

/Loa

>
> Cheers,
> Andy
>
>
> On Mon, May 7, 2018 at 8:05 AM, Andrew G. Malis <agmalis@gmail.com
> <mailto:agmalis@gmail.com>> wrote:
>
>     The following URL is a diff between draft-farrel-mpls-sfc-04
>     and draft-farrel-mpls-sfc-05, when section 6 was updated to change
>     Segment Routing to “Label Stacking”. (Note that the only changes
>     from draft-farrel-mpls-sfc-05 to draft-ietf-mpls-sfc-00 were the
>     name and date change).
>
>     https://tools.ietf.org/rfcdiff?url2=draft-farrel-mpls-sfc-05.txt
>     <https://tools.ietf.org/rfcdiff?url2=draft-farrel-mpls-sfc-05.txt>
>
>     If you examine the changes to section 6, it’s pretty clear (at least
>     to me) that the changes are really just cosmetic in nature, such as
>     removing a reference to draft-ietf-spring-segment-routing and
>     changing a few terms here and there.
>
>     That, combined with the fact that the MPLS WG had never discussed
>     “Label Stacking” in a draft (never mind an RFC) prior to the
>     introduction of Segment Routing leaves me to conclude that section 6
>     really does need to be removed in order to comply with the WG
>     concerns about -04 and earlier revisions of draft-farrel.
>
>     Thanks,
>     Andy
>
>
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>

--

Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls