Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00

[Xuxiaohu <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, June 04, 2014 7:34 PM
> To: Xuxiaohu; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: Request for WG adoption of draft-xu-isis-mpls-elc-00
> 
> Worst scenario (that I would not push for :) ) : What would you do with your
> capability if the conclusion is that EL insertion would not be supported for
> stacked tunnels because too complex ?

I have to disagree with your assumption. At least for option 1 (i.e., inserting a single EL at the bottom of the LSP stack), do you believe it's too complex? In addition, remember that one of the use cases of SPRING is IGP-based MPLS Tunneling (see section 2 of draft-filsfils-spring-segment-routing-use-cases-00).

> What's the problem for you to delay a bit your doc ? As it will never been
> implemented until there is an EL insertion solution ...

It's no problem for me to delay a bit as long as that delay is meaningful.

Best regard,
Xiaohu

> 
> -----Message d'origine-----
> De : Xuxiaohu [mailto:[e-mail]] Envoyé : mercredi 4 juin 2014
> 10:22 À : LITKOWSKI Stephane SCE/IBNF; [e-mail] Cc :
> [e-mail]; [e-mail] Objet : RE: Request for
> WG adoption of draft-xu-isis-mpls-elc-00
> 
> Hi Stephane,
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]
> > Sent: Wednesday, June 04, 2014 2:42 PM
> > To: Xuxiaohu; [e-mail]
> > Cc: [e-mail]; [e-mail]
> > Subject: RE: Request for WG adoption of draft-xu-isis-mpls-elc-00
> >
> > Hi,
> >
> > I completely agree this is orthogonal, but the solution for adding EL
> > is stacked tunnels is unfortunately not as easy as for a single LSP.
> > I just like to be sure that we would have a consensus on a solution
> > for inserting the ELC/EL before worrying on encoding the capability.
> > What would happen if we cannot have a consensus on the solution for
> > the label insertion ? It just a
> 
> Since the ELC advertisement is orthogonal to the EL insertion solution, it doesn't
> matter whether the consensus on the best EL insertion solution can be reached
> or not. Furthermore, IMHO, since each option has its pros and cons, the final
> result may be "make your own choice according to your network capabilities
> and your applications". However, no matter whichever EL insertion option is
> enabled on the ingress LSR in practice, the ELC advertisement is a necessity.
> Don't you think so?
> 
> Best regards,
> Xiaohu
> 
> > question of delaying a bit ... I don't think this is a big issue ...
> > and may be you can push at your side also to have the solution progressing for
> the label insertion ...
> >
> > Stephane
> >
> >
> > -----Message d'origine-----
> > De : Xuxiaohu [mailto:[e-mail]] Envoyé : mercredi 4 juin
> > 2014
> > 04:16 À : LITKOWSKI Stephane SCE/IBNF; [e-mail] Cc :
> > [e-mail]; [e-mail] Objet : RE:
> > Request for WG adoption of draft-xu-isis-mpls-elc-00
> >
> > Hi Stephane,
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]
> > > Sent: Tuesday, June 03, 2014 8:17 PM
> > > To: Xuxiaohu; [e-mail]
> > > Cc: [e-mail]; [e-mail]
> > > Subject: RE: Request for WG adoption of draft-xu-isis-mpls-elc-00
> > >
> > > Hi,
> > >
> > > IMHO, before defining the capability, I would be more interrested on
> > > seeing some progress on a solution for EL over SPRING. A draft
> > > exists with multiple options, maybe we should wait for one option to
> > > have consensus before worrying about ELC encoding (quite easy part
> > > of the EL for
> > SPRING).
> >
> > IMHO, the following rationale for the EL concept has never been
> > changed no matter the EL mechanism is used for a single LSP or stacked
> > LSPs: An ingress LSR cannot insert ELs for packets going into a given
> > LSP unless the egress LSR of that LSP has indicated that it can
> > process ELs on that LSP. SPRING is just an approach of constructing
> > explicitly routed tunnels using stacked LSPs (see
> > http://tools.ietf.org/html/draft-gredler-spring-mpls-06). Therefore,
> > no matter option 1 (i.e., inserting a single EL at the bottom of the
> > LSP stack), option 2(i.e., inserting an EL at every LSP of the LSP
> > stack), option 3 (i.e., re-uses the EL of the terminated LSP for the
> > next inner LSP) or option 4 (i.e., inserting ELs at readable label stack depths) is
> used, the ELC advertisement is necessary. In other word, the ELC advertisement
> mechanism is orthogonal to the EL inserting options.
> >
> > Best regards,
> > Xiaohu
> >
> > > Stephane
> > >
> > > -----Message d'origine-----
> > > De : Isis-wg [mailto:[e-mail]] De la part de
> > > Xuxiaohu
> > Envoyé :
> > > samedi 31 mai 2014 10:05 À : [e-mail] Cc :
> > > [e-mail]; [e-mail] Objet :
> > > [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00
> > >
> > > Hi WG co-chairs,
> > >
> > > This draft (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00)
> > > describes how to advertise the MPLS Entropy Label Capability (ELC)
> > > using IS-IS in SPRING networks. Since
> > > (http://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensio
> > > ns
> > > -00) has been adopted as a WG draft, as co-authors of
> > > draft-xu-isis-mpls-elc-00, we hope you could consider the WG
> > > adoption for
> > this draft as well.
> > >
> > > Best regards,
> > > Xiaohu (on behalf of all-authors)
> > >
> > > _______________________________________________
> > > Isis-wg mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/isis-wg
> > >
> > >
> >
> _____________________________________________________________
> > >
> >
> ____________________________________________________________
> > >
> > > Ce message et ses pieces jointes peuvent contenir des informations
> > > confidentielles ou privilegiees et ne doivent donc pas etre
> > > diffuses, exploites ou copies sans autorisation. Si vous avez recu
> > > ce message par erreur, veuillez le signaler a l'expediteur et le
> > > detruire ainsi que les pieces jointes. Les messages electroniques
> > > etant susceptibles d'alteration, Orange decline toute responsabilite
> > > si ce message a ete altere,
> > deforme ou falsifie. Merci.
> > >
> > > This message and its attachments may contain confidential or
> > > privileged information that may be protected by law; they should not
> > > be distributed, used or copied without authorisation.
> > > If you have received this email in error, please notify the sender
> > > and delete this message and its attachments.
> > > As emails may be altered, Orange is not liable for messages that
> > > have been modified, changed or falsified.
> > > Thank you.
> >
> >
> >
> _____________________________________________________________
> >
> ____________________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> > que les pieces jointes. Les messages electroniques etant susceptibles
> > d'alteration, Orange decline toute responsabilite si ce message a ete altere,
> deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not
> > be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and
> > delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have
> > been modified, changed or falsified.
> > Thank you.
> 
> 
> _____________________________________________________________
> ____________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou
> copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le
> signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration, Orange decline toute responsabilite
> si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed, used
> or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this
> message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.