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

[<[e-mail]>]

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 ? 

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 ...


-----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.