Hi Jeff,

As for per-link MSD information, I have the following comments:

1) I wonder whether you have considered the implementation differences on the 
label stack imposition process among different vendors. More specially, some 
chooses to impose the label stack on ingress line-cards while others choose to 
impose the label stack on egress line-cards due to different tradeoffs. For 
example, when a packet arrives at interface A of linecard X while departuring 
from interface B of linecard Y, assume the MSD type 1 values of linecard A and 
B are different, which interface's MSD value should be taken into account when 
calculating a SR path. Does it require IGP or BGP-LS to be extended to 
advertise the manner of label stack imposition of a given node as well (i.e., 
imposition on ingress or egress linecard)?

2) In the SID-binding case, if the incoming interface or outgoing interface for 
a given packet received by the Binding-SID anchor node is changed on the fly 
due to whatever reasons (e.g., FRR or ECMP ), how to deal with such case?

Best regards,
Xiaohu 

> -----邮件原件-----
> 发件人: Jeff Tantsura [mailto:[email protected]]
> 发送时间: 2017年12月23日 2:50
> 收件人: Xuxiaohu; Les Ginsberg (ginsberg); Ketan Talaulikar (ketant); Christian
> Hopps; [email protected]
> 抄送: [email protected]; [email protected]
> 主题: Re: 答复: 答复: [Isis-wg] WG Last Call for
> draft-ietf-isis-segment-routing-msd-07
> 
> Xiaohu,
> 
> PCEP and ISIS(OSPF) are quite different in their functionality and not meant 
> to
> do the same thing. Wrt SR ecosystem, PCEP is optional, while IGP’s are
> mandatory.
> When it comes to a node capability, PCEP and IGP’s provide same information
> and fully aligned, however more granular, per link information is only 
> available
> in IGPs, and this is as per design (not a bug).
> PCEP SR draft (which I’m co-author of) will be last called soon, please make
> sure you provide your comments to the PCE WG.
> 
> The intention of this thread is to last call 
> draft-ietf-isis-segment-routing-msd,
> that has Type 1 defined and creates IANA registry for the future Types.
> I’d appreciate your comments specifically to the draft, and if you have got 
> any
> technical objection, would be happy to address them.
> 
> Thanks!
> 
> Cheers,
> Jeff
> 
> -----Original Message-----
> From: Xuxiaohu <[email protected]>
> Date: Thursday, December 21, 2017 at 16:42
> To: Jeff Tantsura <[email protected]>, "Les Ginsberg (ginsberg)"
> <[email protected]>, "Ketan Talaulikar (ketant)" <[email protected]>,
> Christian Hopps <[email protected]>, "[email protected]" <[email protected]>
> Cc: "[email protected]" <[email protected]>,
> "[email protected]"
> <[email protected]>
> Subject: 答复: 答复: [Isis-wg] WG Last Call for
> draft-ietf-isis-segment-routing-msd-07
> 
>     Jeff,
> 
>     IMHO, the MSD or the MSD(type 1) just indicates a certain label imposition
> capability which should be signaling-agnostic. More specially, the MSD or
> MSD(type1) capability could be signaled via IGP, BGP or PCEP.
> 
>     If the semantic of MSD (type 1) as defined in your IGP-MSD draft equals 
> the
> semantics of MSD as defined in PCEP-SR draft, I believe it'd better to iron 
> out
> such terminology inconsistency ASAP.
> 
>     Best regards,
>     Xiaohu
> 
>     > -----邮件原件-----
>     > 发件人: Jeff Tantsura [mailto:[email protected]]
>     > 发送时间: 2017年12月22日 5:22
>     > 收件人: Xuxiaohu; Les Ginsberg (ginsberg); Ketan Talaulikar (ketant);
> Christian
>     > Hopps; [email protected]
>     > 抄送: [email protected]; [email protected]
>     > 主题: Re: 答复: [Isis-wg] WG Last Call for
> draft-ietf-isis-segment-routing-msd-07
>     >
>     > Xuxiaohu,
>     >
>     > To clarify:
>     > The concept had been developed in both, in parallel, however PCEP
>     > implementation is limited (node only, PCC in question has to have PCEP
> sessions
>     > with the PCE), and this is clearly stated in the draft – if MSD is known
> from both
>     > sources (PCEP and IGP/BGP-LS) the later takes precedence. IGP drafts are
> the
>     > source of truth when it comes to semantics definitions.
> 
> 
> 
>     > Personally, I don’t see any confusion wrt name, all drafts have been
> around for
>     > quite some time, reviewed by many people, presented in academia and
>     > networking events, noone was ever confused…
>     >
>     > I’m not sure about value of your proposal either, and I’d leave the
> decision
>     > what to use to people who are the consumers of the technology, those
> who are
>     > going to implement it (at least 3 MSD implementations are on their
> ways).
>     >
>     > As the last point – we are not “considering” expanding, the draft is 
> clear
> about
>     > the future extensions to come and encoding is done in a way to 
> facilitate
> such
>     > extensions.
>     > This is the working group last call for the draft, not a discussion 
> whether
> we
>     > should proceed with the technology:
>     > If you see any technical problems with the solution proposed – I’d be
> the first
>     > to listen to you and address them!
>     >
>     > Happy holidays!
>     >
>     > Cheers,
>     > Jeff
>     >
>     > -----Original Message-----
>     > From: Xuxiaohu <[email protected]>
>     > Date: Wednesday, December 20, 2017 at 18:40
>     > To: "Les Ginsberg (ginsberg)" <[email protected]>, "Ketan Talaulikar
> (ketant)"
>     > <[email protected]>, Christian Hopps <[email protected]>,
> "[email protected]"
>     > <[email protected]>
>     > Cc: "[email protected]" <[email protected]>,
>     > "[email protected]"
>     > <[email protected]>
>     > Subject: 答复: [Isis-wg] WG Last Call for
> draft-ietf-isis-segment-routing-msd-07
>     > Resent-From: <[email protected]>
>     > Resent-To: <[email protected]>, <[email protected]>,
>     > <[email protected]>, <[email protected]>
>     > Resent-Date: Wed, 20 Dec 2017 18:40:16 -0800 (PST)
>     >
>     >     Hi Les,
>     >
>     >     If I understand it correctly, the MSD concept was originated from
>     > (https://tools.ietf.org/html/draft-ietf-pce-segment-routing-11#page-7) 
> as
>     > described below:
>     >
>     >     "The "Maximum SID Depth" (1
>     >        octet) field (MSD) specifies the maximum number of SIDs (MPLS
> label
>     >        stack depth in the context of this document) that a PCC is
> capable of
>     >        imposing on a packet."
>     >
>     >     Before considering expanding the semantics of the MSD concept as
> defined
>     > in the above PCE-SR draft, how about first considering renaming the
> capability
>     > of imposing the maximum number of labels so as to eliminate possible
>     > confusions, e.g., Writable Label-stack Depth (WLD) as opposed to the
> Readable
>     > Label-stack Depth (RLD) as defined in
>     > (https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc) and
>     > (https://tools.ietf.org/html/draft-ietf-isis-mpls-elc) ?
>     >
>     >     Best regards,
>     >     Xiaohu
>     >
>     >     > -----邮件原件-----
>     >     > 发件人: Isis-wg [mailto:[email protected]] 代表 Les
> Ginsberg
>     > (ginsberg)
>     >     > 发送时间: 2017年12月21日 4:02
>     >     > 收件人: Ketan Talaulikar (ketant); Christian Hopps;
> [email protected]
>     >     > 抄送: [email protected];
> [email protected]
>     >     > 主题: Re: [Isis-wg] WG Last Call for
> draft-ietf-isis-segment-routing-msd-07
>     >     >
>     >     > Ketan -
>     >     >
>     >     > Thanx for the comments.
>     >     > I think we do want to allow MSD support for values other than
> imposition
>     >     > values. We will revise the text so we are not restricted to only
> imposition
>     > cases.
>     >     >
>     >     >   Les
>     >     >
>     >     >
>     >     > > -----Original Message-----
>     >     > > From: Ketan Talaulikar (ketant)
>     >     > > Sent: Wednesday, December 20, 2017 1:51 AM
>     >     > > To: Christian Hopps <[email protected]>; [email protected]
>     >     > > Cc: [email protected];
> [email protected]
>     >     > > Subject: RE: [Isis-wg] WG Last Call for
>     >     > > draft-ietf-isis-segment-routing-msd-07
>     >     > >
>     >     > > Hello,
>     >     > >
>     >     > > I support this document and would like to ask the authors and
> WG to
>     >     > > consider if we can expand the scope of this draft to not just
>     >     > > "imposition" of the SID stack but also other similar limits 
> related
> to
>     > other
>     >     > actions (e.g.
>     >     > > reading, processing, etc.). With Segment Routing, we are coming
> across
>     >     > > various actions that nodes need to do with the SID stack for
> different
>     >     > > purposes and IMHO it would be useful to extend the MSD ability
> to
>     >     > > cover those as they arise.
>     >     > >
>     >     > > Thanks,
>     >     > > Ketan
>     >     > >
>     >     > > -----Original Message-----
>     >     > > From: Isis-wg [mailto:[email protected]] On Behalf Of
> Christian
>     >     > > Hopps
>     >     > > Sent: 20 December 2017 14:03
>     >     > > To: [email protected]
>     >     > > Cc: [email protected];
> [email protected]
>     >     > > Subject: [Isis-wg] WG Last Call for
>     >     > > draft-ietf-isis-segment-routing-msd-07
>     >     > >
>     >     > >
>     >     > > The authors have asked for and we are starting a WG Last Call on
>     >     > >
>     >     > >
> https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/
>     >     > >
>     >     > > which will last an extended 4 weeks to allow for year-end PTO
> patterns.
>     >     > >
>     >     > > An IPR statement exists:
>     >     > >
>     >     > >
>     >     > >
> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-is
>     >     > > is-
>     >     > > segment-routing-msd
>     >     > >
>     >     > > Authors please reply to the list indicating whether you are 
> aware
> of
>     >     > > any
>     >     > > *new* IPR.
>     >     > >
>     >     > > Thanks,
>     >     > > Chris.
>     >     > >
>     >     > > _______________________________________________
>     >     > > Isis-wg mailing list
>     >     > > [email protected]
>     >     > > https://www.ietf.org/mailman/listinfo/isis-wg
>     >     >
>     >     > _______________________________________________
>     >     > Isis-wg mailing list
>     >     > [email protected]
>     >     > https://www.ietf.org/mailman/listinfo/isis-wg
>     >
>     >
> 
> 
> 

_______________________________________________
Isis-wg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/isis-wg

Reply via email to