Subject: Re: [Pals] PALS WGLC on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp

From: Stewart Bryant <[email-masked]>
Date: Wed, 2 Dec 2015 11:32:15 +0000

Huub, Sasha, authors,

What is the resolution on this point?

Stewart

On 16/11/2015 14:38, Alexander Vainshtein wrote:
>
> Huub hi!
>
> You have written (with regard to IETF vs. ITU-T Global ID formats):
>
> The number of bits/bytes used for the ID is the same, it is only the 
> format of the ID that is different.
> Why make an explicit reference?
>
> I may be missing of misunderstanding something but:
>
> ·As per RFC 6923 ITU-T Global ID is provided by concatenating 
> 2-character Country Code with the ITU-T-assigned alphanumeric string 
> of up to 6 characters. So the total length of the Global_ID is /8 bytes/.
>
> ·As per RFC 6370 the IETF Global ID is /4 bytes/.
>
> This does not look like the same number of bits/bytes to me.
>
> Regards,
>
> Sasha
>
> Office: +972-39266302
>
> Cell: +972-549266302
>
> Email: [email-masked]
>
> *From:*Pals [mailto:[email-masked]] *On Behalf Of *Huub van 
> Helvoort
> *Sent:* Monday, November 16, 2015 3:56 PM
> *To:* [email-masked]
> *Subject:* Re: [Pals] PALS WGLC on 
> draft-ietf-pals-mpls-tp-pw-over-bidir-lsp
>
> All,
>
> Triggered by the discussion here is my 2 (euro)cent:
>
>
> > The intention/logical is that the co-routed bidirectional LSP should 
> be used if
> > there have, otherwise two unidirectional LSPs with the same route can be
> > used.
> >
> > How about we add some text to make this clear and give some cautions 
> to the
> > case of "two unidirectional LSPs with the same route"?
>
> */[[Sasha]] This would be good enough IMHO./*
>
> [Mach] Great!
>
>
> The advantage of co-routed bidirectional LSPs is that the sink MEP
> is co-located with the source MEP and they have a connection required
> to return OAM information (packet loss, delay, signal fail).
> This is a requirement for MPLS-TP.
>
> With two uni-directional LSPs this is not obvious, and in case they are
> used should be noted explicitly.
>
>
> > > 2.  The draft seems to use MPLS-TP Node Identifiers as defined in RFC
>
> > > 6370. I have two concerns in this regard:
> > > a. RFC 6923 defines an alternative format of MPLS-TP identifiers based
> > > on ITU-T.  But the draft neither supports this alternative format nor
> > > explicitly states that it must be supported
> >
> > There is no intention to support the ITU-T based identifier. Do you 
> suggest to
> > make this explicitly?*/[[Sasha]] Yes, with an Informative reference 
> to 6923. I assume that Informative would be sufficient for something 
> that is not going to be implemented��. /*
>
> [Mach] OK.
>
> The number of bits/bytes used for the ID is the same, it is only
> the format of the ID that is different.
> Why make an explicit reference?
>
> Best regards, Huub.
>
>
>
> -- 
> *****************************************************************
>                请记住，你是独一无二的，就像其他每一个人一样  
>
>
> _______________________________________________
> Pals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pals