Subject: Fwd: Progressing the three inter-domain I-Ds

From: JP Vasseur <[email-masked]>
Date: Wed, 7 Feb 2007 10:57:13 -0500

Hi Dimitri,

Just double checking that there's no pending issues - see in line

Begin forwarded message:

> From: JP Vasseur <[email-masked]>
> Date: January 16, 2007 9:42:57 AM EST
> To: [email-masked]
> Cc: "Adrian Farrel" <[email-masked]>, [email-masked],  
> [email-masked]
> Subject: Re: Progressing the three inter-domain I-Ds
>
> Hi Dimitri,
>
> On Jan 13, 2007, at 6:49 AM, Dimitri.Papadimitriou@alcatel- 
> lucent.be wrote:
>
>> hi adrian
>>
>> o) a couple of generic comments on the third doc
>>
>> - the doc. states applicability to GMPLS but sometimes only ref.  
>> MPLS-TE
>> signaling further on e.g. section 3.1
>>
>> " - The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209])."
>>
>> and many others in section 4.
>>
>
> ok.

Reference to RFC3473 added.

>
>> - the are many comparison with PCE technique along the doc. - well  
>> that's
>> fine but outside the scope of the document except if the purpose  
>> is to
>> indicate how different techniques can be combined together and which
>> interop issues may result from it
>>
>
> Because there are indeed two path computation techniques, it is  
> useful to keep these references in order to provide a fair  
> comparison. We could of course come up with a separate  
> applicability ID, but there are already quite a few related IDs,  
> thus it is preferable to keep the text here. I'll double check if  
> there's any redundancy though.
>
>> o) a couple of specific comments
>>
>> end of section 2:
>>
>> section 3.1: "* The complete list of boundary LSRs along the path"
>> -> list of domain identifier e.g. AS numbers also applies here ?
>>
>> last § of section 3.1 is the most important one, signaling  
>> protocol are
>> independent of the routing topology itself, i.e. not because a  
>> node is
>> an ABR or an ASBR that comp. occurs but simply because he has no path
>> to reach the next (loose) hop - an intermediate node should still  
>> maintain
>> capacity to perform such operation
>>
>> section 3.3 "The path computation
>>    technique described in this document applies to the case of a  
>> single
>>    AS made of multiple IGP areas, multiples ASs made of a single IGP
>>    areas or any combination of the above.  For the sake of  
>> simplicity,
>>    each routing domain will be considered as single area in this
>>    document. "
>>
>> -> not sure to understand the reasoning, at the end these examples  
>> must
>> remain illustrative and not restrict applicability - all these  
>> tutorial
>> like material should better go in an appendix -
>
>

> We prefer to keep it there

>
>
>>
>> section 3.1 "In any case,
>>    no topology or resource information needs to be distributed  
>> between
>>    domains (as mandated per [RFC4105] and [RFC4216]), which is  
>> critical
>>    to preserve IGP/BGP scalability and confidentiality in the case  
>> of TE
>>    LSPs spanning multiple routing domains."
>>
>> then Section 4
>> "In terms of computation of an inter-AS TE LSP path, an interesting
>>    optimization technique consists of allowing the ASBRs to flood  
>> the TE
>>    information related to the inter-ASBR link(s) although no IGP  
>> TE is
>>    enabled over those links (and so there is no IGP adjacency over  
>> the
>>    inter-ASBR links).  ...
>> "Thanks to such an optimization, the inter-ASBRs TE link information
>>    corresponding to the links originated by the ASBR is made  
>> available
>>    in the TED of other LSRs in the same domain that the ASBR  
>> belongs to."
>>
>> but after
>> "Note that no topology
>>    information is flooded and these links are not used in IGP SPF
>>    computations.  Only the TE information for the outgoing links
>>    directly connected to the ASBR is advertised."
>>
>> -> can one of the author clarify 1) is flooding involved or not ?
>
> I'll be happy to clarify. The idea is to flood the TE info for the  
> Inter-AS link(s). Note that this does not contradict the  
> requirements of RFC4216:
> (1) Confidentiality relates to the topology of another domain: the  
> TE information flooded in a domain is only augmented by Inter-AS  
> links, not to any link in another domain.
> (2) Scalability: of course, flooding the TE info of a few Inter-AS  
> links will not compromise the scalability of the IGP.

Do we agree ?

>
>> 2) what get's flooded and under which conditions 3) what is the
>> scope of the flooding 4) how this mechanism positions against the
>> requirements of 4105 and 4216
>>
>
> Did I clarify ? If so, I'll add a paragraph in the ID.
>
>>
>> o) a couple of edits
>>
>> section 1:
>>
>> ABR Router, ASBR Router - redundant R
>>
>> the most important def. is the "domain" def. which can be found in  
>> the
>> frm doc but not recorded here this would clarify sentence like
>>
>> "The mechanisms proposed in this document are also applicable to MPLS
>>  TE domains other than IGP areas and ASs."
>>
>> ref. H-LSP and S-LSP with the appropriate docs
>>
>> state that inter-domain recovery is going to be addressed in a set of
>> specific docs
>
> Thanks for the edits.

Thanks.

JP.

>
> JP.
>
>>
>> hope this will help,
>> - d.
>>
>>
>>
>>
>> "Adrian Farrel" <[email-masked]>
>> Sent by: [email-masked]
>> 09/01/2007 23:13
>> Please respond to "Adrian Farrel"
>>
>>         To:     <[email-masked]>
>>         cc:
>>         Subject:        Progressing the three inter-domain I-Ds
>>
>>
>> Hi,
>>
>> We now have updated versions of the three inter-domain signaling I- 
>> Ds:
>>
>> - draft-ietf-ccamp-inter-domain-rsvp-te-04.txt
>> - draft-ietf-ccamp-lsp-stitching-04.txt
>> - draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt
>>
>> Our plan is:
>> 1. WG chairs do detailed review over the next couple of weeks
>> 2. Editors apply necessary updates
>> 3. We hold a WG last call for the three I-Ds together
>>
>> If you are interested in this work, I suggest that now might be a  
>> good
>> time
>> to remind yourself about the I-Ds, have a good read, and see if  
>> you can
>> get
>> any substantial comments in to coincide with the WG chairs' review.
>>
>> Thanks,
>> Adrian
>>
>>
>>
>>
>